1. Field of the Invention
The present invention generally relates to development, deployment, and management of enterprise tiered applications in which multiple instances of the same code and configuration are deployed, typically on separate machines connected on a network. More specifically, an agreed-upon election process, extensible configuration capability, and task allocation message format allow autonomic application differentiation for leader election, which leader thereinafter assigns configuration(s) and tasks among the multiple instances of currently-deployed code modules.
2. Description of the Related Art
Modern application architectures and frameworks have provided some common development, deployment, and management capabilities. However, enterprise applications, in particular, have challenges to provide a consistent level of service to a specified number of users at an acceptable level of performance.
Java 2 Enterprise Edition (J2EE)™ is a Java™ runtime environment primarily designed, developed and supported by Sun Microsystems. It was specifically architected to support enterprise tiered application development, deployment, and management.
For purposes of the discussion hereinbelow, “enterprise application” or “enterprise-capable application” refers to an application designed to be distributed so that potentially a plurality of such identical modules are simultaneously deployed. Enterprise applications might be deployed to multiple machines but a single machine can also have multiple deployments at the same time. An enterprise application typically serves a large audience of consumers, users, machines or potentially other applications, although the actual size of an audience at any one time is not to be considered a limitation of the present invention. As implemented on a computer or computer network, an enterprise application can be considered as a look-alike software module.
FIG. 1 shows an exemplary functional diagram of a conventional enterprise application deployment 100 relating to, for example, one or more data sources 101, as interconnected functionally by the dotted lines 102, 103. The components 104-107 might be hardware components, such as servers, but more typically for purpose of this discussion, would be software enterprise applications respectively located in separate physical component or even a single component, such as a server 104. Server 104 might, for example, serve as an entry for users into the data sources 101 via a computer network (not shown), such as the Internet. Messaging hub 107 serves as a communication center that appropriately forwards messages between the nodes.
Assuming application servers 105, 106 as being enterprise applications, then it can be seen that each application server 105, 106 could be further comprised of submodules, such as a web application module 108, a web service 109, and an EJB module 110. Enterprise JavaBeans™ (EJB) technology is the server-side component architecture for the Java 2 Platform, Enterprise Edition (J2EE) platform. EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java™ technology. Therefore, as exemplarily shown in FIG. 1, there are at least two implemented enterprise applications 105, 106 at the same time in this example.
Typically, an enterprise application will have a primary function, but is often exposed to other secondary functions and to other applications. For example, each enterprise application 105, 106 might have a primary function to provide a single point of access to manage telephone contacts and/or other emergency contacts for employees of a company. However, this same enterprise application 105, 106 might also be used to provide other services or functions that allow other applications to leverage the information and/or software code used to support the primary function.
For example, a secondary function of enterprise application modules 105, 106 might be exposing the telephone and emergency contact information to another application residing on application servers 105,106 that defines emergency procedures to be followed as predefined company policy for handling emergencies. The emergency procedure application on application servers 105, 106 consumes data via a web service, remote EJB, or other communication from the emergency contact management application also on application servers 105,106. Both the first application and the second application can be considered as an enterprise application for purpose of this discussion.
In general, enterprise applications require architectures that support two main types of scaling, vertical and horizontal. Vertical scaling is when an application is deployed on the same hardware to maximize utilization of available resources. Horizontal scaling, which is more popular, is more often used to achieve redundancy and higher performance for overall reliability.
In both cases of scaling, application components are typically literally deployed on multiple machines. Each copy represents a set piece of function designed to operate exactly like each other. This architecture is currently exemplified by Java J2EET™. J2EE™ web applications provide a single manageable bundle for development and deployment, and this feature has simplified both development and deployment of application components.
Applications are often deployed in layers to provide more options for scalability. For example, there might be a need to have more web servers (serving static content) than web application servers (dynamic content). Legacy and maintenance components are often deployed as one-off solutions. These components often fail to leverage the benefits of a single bundle development and deploy architecture like J2EE™.
Although modular application architecture, development and deployment provide efficiencies over past systems, there are often several components managed outside of the application design. This divergence will continue to grow over time.
That is, enterprise applications often require dedicated independent components which are managed apart from the main application. Currently, skilled human involvement is usually required to manage and maintain such systems. Without some method of oversight, the multiple instances can work against each other, causing problems such as data corruption or poor performance. The multiple instances might, for example, poise the risk of task collision and might introduce additional unwanted network traffic or database activity.
Therefore, for application architecture, scalability is often addressed by creating layered architecture and employing the use of horizontal scaling, that is, essentially throwing hardware at the problem.
There are components that do not fit within these frameworks. Specifically, legacy systems and maintenance applications are two areas that architectures and frameworks tend to ignore. These items are often deployed as one-off solutions without much care to scalability and reliability. It is not uncommon for this approach to introduce unsynchronized code branches, duplication of effort, etc., everything that one might expect by introducing multiple work streams to address an overall solution.
One of the reasons they are deployed as stand-alone applications has to do with there being no common way to scale horizontally and automatically have parts of the deployment perform specialized tasks (e.g., without human intervention, such as using configuration files). This problem is compounded should it be necessary or desirable to modify or redefine the specialized task to be performed.
Thus, a need continues to exist for improvement in the implementation of modular application architecture.